Delta transfers in distributed file systems

ABSTRACT

Disclosed are novel methods and apparatus for delta transfers in distributed file systems. In an embodiment, a communication system for transferring a delta of a file is disclosed. The communication system includes a sender site, a file transfer system, and a receiver site. The sender site includes a database with a trove section and a transfer section. The file transfer system includes a trove reader and a transfer reader. The trove reader may communicate with the trove and transfer sections. The transfer reader may have access to the transfer section. The receiver site receives the file delta from the transfer reader. The receiver site includes a file installer, which patches a previously installed version of the file with the file delta.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application relates to application Ser. No. ______, entitled“Distributed Configuration-Managed File Synchronization Systems,”(Attorney Docket No. 5858P7244) and application Ser. No. ______,entitled “Persistent Queuing for Distributed File Systems,” (AttorneyDocket No. 5858P7410), both filed concurrently herewith and in the nameof the present assignee. All these documents are hereby incorporated byreference for all purposes.

FIELD OF INVENTION

The subject of this application relates generally to the field of datatransfer. More particularly, an embodiment of the present inventionrelates to delta transfers in distributed file systems.

BACKGROUND OF INVENTION

As the use of digital data becomes more prominent in everyday life, theneed for access to reliable data sources increases. For example, a usermay need regular access to data that can be physically located acrossdifferent buildings or even around the world. This is often the casewith respect to large company projects that may involve many groupsworldwide working on a same solution.

As these types of joint projects become more commonplace, so does theneed for having access to such data in real-time. In other words, thedata accessed by each remote site will need to be current whether thatdata is stored locally or halfway around the world. Accordingly, theusers need to have access to the latest version of the data as soon asit is released into the system from any site.

In many current implementations utilizing transmission controlprotocol/Internet protocol (TCP/IP), file transfer protocol (FTP), andother similar facilities (e.g., RSYNC command provided in Unix systems)are utilized to maintain data amongst remote sites. These tools,however, are generally useful only for transferring files from one pointto the next. Moreover, automation of these tools only results insynchronization among multiple sites when a batch update or a nightlysynchronization is performed. Also, if one of the remote sites goes downor cannot accept external data, the data may be dropped and unavailable.

One of the biggest challenges for a distributed file system is theefficient utilization of the available network bandwidth. This can bekey to an effective real-time file synchronization utility, especiallyin a large multi-user community sprawled across a country or even theglobe. The RSYNC utility uses an internal computation for transferringonly the change in data to a remote site. This internal computation,however, cannot be harnessed by a multi-site file system using, forexample, a revision control system (RCS) at the backend. Also, the RSYNCutility computes the change on an entire file without regard fordifferent versions of a same file.

SUMMARY OF INVENTION

The present invention, which may be implemented utilizing ageneral-purpose digital computer, includes novel methods and apparatusto provide delta transfers in distributed file systems that can provideready access to data among remote users. In an embodiment, acommunication system for transferring a delta of a file is disclosed.The communication system includes a sender site, a file transfer system,and a receiver site. The sender site includes a database with a trovesection and a transfer section. The file transfer system includes atrove reader and a transfer reader. The trove reader may communicatewith the trove and transfer sections. The transfer reader may haveaccess to the transfer section. The receiver site receives the filedelta from the transfer reader. The receiver site includes a fileinstaller, which patches a previously installed version of the file withthe file delta.

In another embodiment, the communication system utilizes an availablebandwidth more efficiently by transferring the file delta between thesender site and the receiver site.

In a further embodiment, a method of transferring a delta of a file isdisclosed. The method includes providing a sender site, a file transfersystem, and a receiver site. The sender site includes a database, whichhas a trove section and a transfer section. The file transfer system hasa trove reader and a transfer reader. The trove reader communicates withthe trove and transfer sections. The transfer reader has access to thetransfer section. The receiver site receives the file delta from thetransfer reader. The receiver site includes a file installer, whichpatches a previously installed version of the file with the file delta.

BRIEF DESCRIPTION OF DRAWINGS

The present invention may be better understood and its numerous objects,features, and advantages made apparent to those skilled in the art byreference to the accompanying drawings. These drawings, however, shouldnot be taken to limit the invention to the specific embodiments, but arefor explanation and understanding only.

FIG. 1 illustrates an exemplary computer system 100 in which the presentinvention may be embodied;

FIG. 2 illustrates an exemplary network configuration 200 in accordancewith an embodiment of a present invention;

FIG. 3 illustrates an exemplary communication system 300 in accordancewith an embodiment of a present invention;

FIG. 4 illustrates an exemplary block diagram of a communication system400 in accordance with an embodiment of the present invention; and

FIG. 5 illustrates an exemplary flow chart of a transfer method 500 inaccordance with an embodiment of the present invention.

The use of the same reference symbols in different drawings indicatessimilar or identical items.

DETAILED DESCRIPTION

In the following description, numerous details are set forth. It will beapparent, however, to one skilled in the art, that the present inventionmay be practiced without these specific details. In other instances,well-known structures and devices are shown in block diagram form,rather than in detail, in order to avoid obscuring the presentinvention.

Reference in the specification to “one embodiment” or “an embodiment”means that a particular feature, structure, or characteristic describedin connection with the embodiment is included in at least one embodimentof the invention. The appearances of the phrase “in one embodiment” invarious places in the specification are not necessarily all referring tothe same embodiment.

FIG. 1 illustrates an exemplary computer system 100 in which the presentinvention maybe embodied in certain embodiments. The system 100comprises a central processor 102, a main memory 104, an input/output(I/O) controller 106, a keyboard 108, a pointing device 110 (e.g.,mouse, track ball, pen device, or the like), a display device 112, amass storage 114 (e.g., hard disk, optical drive, or the like), and anetwork interface 118. Additional input/output devices, such as aprinting device 116, may be included in the system 100 as desired. Asillustrated, the various components of the system 100 communicatethrough a system bus 120 or similar architecture.

In an embodiment, the computer system 100 includes a Sun Microsystemscomputer utilizing a SPARC microprocessor available from several vendors(including Sun Microsystems of Palo Alto, Calif.). Those with ordinaryskill in the art understand, however, that any type of computer systemmay be utilized to embody the present invention, including those made byHewlett Packard of Palo Alto, Calif., and IBM-compatible personalcomputers utilizing Intel microprocessor, which are available fromseveral vendors (including IBM of Armonk, N.Y.). Also, instead of asingle processor, two or more processors (whether on a single chip or onseparate chips) can be utilized to provide speedup in operations. It isfurther envisioned that the processor 102 may be a complex instructionset computer (CISC) microprocessor, a reduced instruction set computing(RISC) microprocessor, a very long instruction word (VLIW)microprocessor, a processor implementing a combination of instructionsets, and the like.

The network interface 118 provides communication capability with othercomputer systems on a same local network, on a different networkconnected via modems and the like to the present network, or to othercomputers across the Internet. In various embodiments, the networkinterface 118 can be implemented in Ethernet, Fast Ethernet, wide-areanetwork (WAN), leased line (such as T1, T3, optical carrier 3 (OC3), andthe like), digital subscriber line (DSL and its varieties such as highbit-rate DSL (HDSL), integrated services digital network DSL (IDSL), andthe like), time division multiplexing (TDM), asynchronous transfer mode(ATM), satellite, cable modem, and FireWire.

Moreover, the computer system 100 may utilize operating systems such asSolaris, Windows (and its varieties such as NT, 2000, XP, ME, and thelike), HP-UX, IBM-AIX, Unix, Berkeley software distribution (BSD) Unix,Linux, Apple Unix (AUX), and the like. Also, it is envisioned that incertain embodiments, the computer system 100 is a general purposecomputer capable of running any number of applications such as thoseavailable from companies including Oracle, Siebel, Unisys, Microsoft,and the like.

It is envisioned that the present invention may be applied to systems,which utilize RCS and meta data information, individually or incombination. The RCS can be configured as a backend storage systemincluding the actual files. It is envisioned that RCS may be hidden fromusers. The meta data information can include data about the actualfiles. The meta data may be stored in a database, such as that providedby Sybase, Inc., of Emeryville, Calif. The meta data may includerelational information, block and sector information, file type, and thelike.

FIG. 2 illustrates an exemplary network configuration 200 in accordancewith an embodiment of a present invention. As illustrated, the networkconfiguration 200 includes three hubs (Hub1 202, Hub2 204, and Hub3 206)as an example. The hubs may be configured to communicate with each otherthrough any number of networking tools including a point-to-pointconnection. Each of these hubs may have their own spokes. For example,Hub1 202 may have spokes 208, 210, and 212. Similarly, Hub2 204 may havespokes 214-218 and Hub3 may have spokes 220-224. All spokes on a singlesite may be grouped together to form a local subnet (e.g., with one huband multiple spokes). Each remote site may be connected in a startopology (e.g., with the hub at the center of the star).

Each spoke may have a set of configuration parameters defined in a localor remote database. When the spoke is brought up, the spoke may utilizethe configuration parameters to configure itself or auto-configure.Accordingly, each site may be easily reconfigured by, for example,changing the entries in the database that contains the configurationdata for each site. Each spoke (208-224, for example) can have thefollowing configuration parameters defined, in addition to any alreadyexisting ones:VectorIn: a vector that contains the list of Ids for sites (siteIds)that send files to the spoke;VectorOut: a vector that contains the list of siteIds that receive filesfrom the spoke; and/orPass Through or Store-N-Go Field: this field indicates to the spokewhether that spoke is just a connector or a hub (for example, with abuffer and no central directory) or a spoke (which, for example, makes acopy of the file it is transferring into the spoke's central directory).

Depending on the above parameters, each spoke can then become a hub or aspoke. Furthermore, in an embodiment, all hubs need not be inpass-through mode, and all spokes may be in store-n-go mode. Forexample, on a site, if there is a single spoke, it is unnecessary to addanother hub on the same site. The only spoke can then act as a hub instore-n-go mode. So, each site may be configured as per the requirementsat that site. In an embodiment, some of the advantages of sucharchitecture are that each site only transfers the file once to theother sites, but not to each spoke. This reduces network traffic. Also,such architecture is very scalable, and is highly flexible toaccommodate different configurations at each site.

In some embodiments, it is envisioned that hubs may not have usersworking on them. So, no new files may be created on such hubs. In case ahub hosts users, that hub may be configured similar to a spoke. Forexample, that hub can transfer the given file locally to all spokes, andtransfer a copy to each of the remote hubs.

It is envisioned that a hub may differentiate between the local-domaingenerated file and the file that it received from a foreign domain. Inone embodiment, the receiving entity (or module), for example uponreceiving a file, can check to see if the origin site of the file is thesame domain as the hub. If so, the file does not need to be routed anyfurther and can be just locally copied. On the other hand, if the domainof the origin site is different, the hub knows that it has to transfer acopy of the file to each of the local spokes.

It is also envisioned that this checking may be performed by, forexample, employing a FileReceiver module. The FileReceiver module canreceive files and may run as a thread on a general-purpose computer oran appropriate networking device. The FileReceiver upon receiving a filemay: (1) ensure that the received file is accurate (for example, byperforming checksum validations) and/or (2) check the file origin (andif the file is foreign, the FileReceiver can route the received filelocally). In an embodiment, the step (2) above can be done by theFileReceiver present on a hub rather than on a spoke. In an embodiment,if the FileReceiver module has to route the file, the FileReceivermodule can insert entries into, for example, a transfer table in adatabase (e.g., locally). In one embodiment, there can be one entry pereach local spoke in the database. Another process, e.g., a databasereader (DBReader such as that discussed with respect to FIG. 3), canthen handle additional work for transferring the file.

Accordingly, the routing information can be stored in a database. In anembodiment, with the above-proposed architecture, each hub may knowwhich domain it belongs to, and what spokes exist on its local domain.Also, each spoke may know to which other spokes and hubs is it directlyconnected. For example, an entry in a transfer table can be inserted foreach spoke and/or hub that the given local spoke is directly connectedto. In certain embodiments, the DBReader module on the local spoke canthen handle or initiate the transfers.

FIG. 3 illustrates an exemplary communication system 300 in accordancewith an embodiment of a present invention. The communication system 300includes a sender site 302 and a receiver site 304. The sender site 302includes a database 306 (DB), an RCS 308, a DBReader module 310, and asend daemon 312. It is envisioned that the database 306 may store metadata and other data as required. The RCS may be hidden from users andstore actual files being transferred and/or maintained on the sendersite 302. The DBReader module 310 can be a process that may run on acomputer system (such as that discussed with respect to FIG. 1). Incertain embodiments, the DBReader module 310 may be run on amultitasking system as a process, for example. The DBReader module 310may run on a system continuously. It is envisioned that the DBReadermodule 310 has access to the database 306 and the RCS 308, and canprocess the stored data. The DBReader module 310 may initiate a filetransfer process by, for example, reading a job description from atransfer table stored, for example, in the database 306.

In an embodiment, the DBReader module 310 may further communicate withthe send daemon 312. It is envisioned that the send daemon 312 can beresponsible for sending data from the sender site 302 to the receiversite 304. The send daemon 312 can be a Unix daemon thread or othersimilarly configured process running on a computer system. The senddaemon 312 may be configured to run in the background so it can beactivated with short notice. In one embodiment, the send daemon 312 maybe a thread spawned from the DBReader module 310.

The send daemon 312 may have access to a local queue 314 (internal orexternal to the send daemon 312). The local queue 314 may providestorage capabilities to the send daemon 312. It is envisioned that thelocal queue 314 may be any type of storage such as random access memory(RAM), its varieties such as dynamic RAM (DRAM), static RAM (SRAM),synchronous DRAM (SDRAM), and the like. Further information regardingthe local queue 314 may be found by reference to FIG. 4.

The receiver site 304 includes a database 316, an RCS 318, a monitor320, and a remote server 322. The database 316 and RCS 318 may besimilar to those of the sender site 302 (i.e., database 306 and RCS308). The monitor 320 can be on lookout for information of interest andinform a selected party (e.g., a user) about the status of theinformation desired. For example, the monitor 320 may be a visual aidindicating status of a transfer in real-time. The remote server 322 canhave access to the database 316, RCS 318, and monitor 320. The remoteserver 322 may also have access to a remote queue 323 (RemoteQ). Theremote queue 323 may be a similar device such as that discussed withrespect to the local queue 314. The remote queue 323 can provide theremote server 322 with storage capabilities. It is envisioned that theremote queue 323 may store meta data for the receiver site 304. Also,the remote queue 323 may provide memory for delivered job descriptionswhich are uninstalled. Further information regarding the remote queue323 may be found by reference to FIG. 5.

The sender site 302 can also include one or more file sender(s) 324which may communicate with one or more, respective, file receiver(s)326. This communication may also utilize acknowledge capabilities toensure a file is properly transferred. Other error correctioncapabilities may also be used to ensure proper communication between thefile senders 324 and file receivers 326. Such error correctioncapabilities may include parity checking, M0-5 checksum validation, andthe like. The file senders 324 may hold all information about the filethat is being transferred. Further, it is envisioned that the filesender 324 may perform one or more of the following: physically transfera file from the sender site 302 to the receiver site 304, obtainacknowledgment regarding the transfer, update a ReceivedTime field(indicating when the data sent was received), for example, in thetransfer table that may be stored in the database 306. The file sender324 can be a thread spawned by the send daemon 312.

The file receiver 326 may be responsible for one or more of thefollowing tasks: receiving files over, for example, a TCP socket,re-calculating the checksum, verifying file correctness, copying thefile into the designated buffer area, sending an ACK/NAK signal (toacknowledge receipt or non-receipt), remove the current entry (or row)from queue of the remote server 322, and update the file receiver countat the remote server 322. In some embodiments, the file receiver 326 maybe a thread spawned by a remote server routine.

The sender site 302 can additionally include a command sender 328 forsending commands from the sender site 302 to a command executor (CE) 330on the receiver site 304. It is envisioned that the command sender 328may perform one or more of the following: start a server socket, waitfor the acknowledgment from the command executor 330, and update theappropriate database (such as the database 316). Moreover, the commandsender 328 may be a thread spawned by the remote server 322.Furthermore, the command executor 330 may perform one or more of thefollowing: connect to the command sender 328, execute the command (e.g.,copy data, delete data, and/or delete directory), send acknowledgment,and update information about when an action is done in an appropriatedatabase (such as the database 316). Moreover, the command executor 330may be a thread spawned by the remote server 322.

In an embodiment, the sender site 302 can include a command manager (CmdMgr) 334 and a monitor 336. The monitor 336 may be similar to thatdiscussed with respect to the receiver site 304 (i.e., the monitor 320).The command manager 334 is envisioned to be able to communicate(directly or indirectly) with the remote server 322 and to executecommands. Such commands may, for example, include push data and pulldata, which can be used to change the priority on a file that is beingtransferred, so that it is shipped ahead of or after the rest (or selectones) of the current queue members.

The receiver site 304 can further include one or more file installer(s)332. The file receivers 332 may perform one or more of the following:verify whether meta data of predecessor and object being installed arein place, verify whether the RCS 318 of predecessor is in place, installthe object into the RCS 318, update object's meta data, sendacknowledgment as required, update flags including CompleteTime(indicating the time the installation was complete) and InstallationMessage (any messages resulting from the installation) on, for example,a source database (where the file being installed is located), anddelete any unused buffer files utilized for the installation. It isenvisioned that the file installer 332 may be a thread spawned by theremote server 322.

It is also envisioned that the send daemon 312 may perform one or moreof the following: perform handshake operations between the sender andreceiver sites, initiate a file transfer or a command execution, executea remote method invocation (RMI) call on the remote server 322, transferjob description, request/provide a port number, spawn a file sender(such as 324) along with passing relevant port information, spawn acommand sender (such as 328), wait on the local queue 314 for more jobs,and keep a balance in the number of existing transport channels.Further, the remote server 322 may provide remote methods to the senddaemon 312 to initiate a file transfer or a command execution. Theremote server 322 may also keep an account on file receiver/fileinstaller counts, spawn the file receivers 326 to receive files, andspawn file installers 332 when the remote queue 323 receives a newmember.

The communication system 300 may further include a service provider 338.The service provider 338 may provide a variety of services to the systemcomponents including one or more of the following: handling periodicregistrations from key modules, subscribing and unsubscribing ofavailable monitoring services, routing the monitor messages to thecorresponding monitors, and providing a pointer to the correct log filefor remote modules. It is envisioned that one service provider 338 issufficient for the entire system. In an embodiment, the service provider338 may run on a primary site.

Also, the communication system 300 may further include a databasemanager module (not shown), which may provide useful applicationprogramming interfaces (APIs) to, for example, insert, update, delete,and select information on various tables in the databases present in thecommunication system 300. Such a database manager may be implemented asa Java object.

It is envisioned that an interface between a user command andtransparent transport layer may be a database. More specifically, thisinterface may be a transfer table. Such a transfer table may store therequired information about each file transfer. Each user command, aftersuccessful completion, may in turn deposit a transfer request into thetransfer table. Furthermore, it is envisioned that the DB Reader 310 maybe present on all sites where there is a possibility of users checkingin files. The DB Reader 310 having sensed what needs to be transferredcan buffer the jobs into the respective queues of the destinations. Italso can spawn the send daemon 312, for each destination and from thenon, it may hand over the corresponding queue to it. The send daemon 312may then handle the handshake between itself and the remote server 322,and establish full-duplex communication channels for example, totransfer files and receive acknowledgments. This may involve creation offile sender-file receiver pairs (324 and 326, respectively) on senderand receiver sites, respectively. If the command is other than create orsave data, the command sender 328 and command executor 330 pairs may becreated.

The file sender 324 can transfer a file, and the checksum of that fileover the established channel, and wait for the acknowledgment from thefile receiver 326. The file receiver 326 having received the file mayperform checksum verification between the received checksum, and there-calculated checksum on the receiver site 304. If they tally, apositive ACK maybe sent to the file sender 324. Otherwise, a NAK may besent. Upon receiving an ACK, the file sender 324 may update theReceivedTime in, for example, the transfer table and exit. On receivinga NAK, the file sender 324 may re-transfer the file. The iteration maybe continued until a positive ACK is received, or once the file sender324 times out. If the file sender 324 times out, it may enter a panicstate, and send out e-mails to an appropriate target (such as a systemadministrator).

Once a file is received correctly, the file receiver 326 may copy thefile to its designated buffer area, and enter the job description intothe remote queue 323, and also register the job in an appropriate (e.g.,RemoteQ) table in the database 316. In case of the remote server 322break down, the remote queue 323 may rebuild the required informationfrom the database 316. In such a case, the remote server 322 may start aFileInstaller thread for each file received (such as file installer332). The FileInstaller can be responsible for the installation of thefile in the RCS 318, and for updating a VersionHere bit in aFileVersions table in the database 316. The FileInstaller may perform aseries of checks for the presence of both the predecessor's and thefile's meta-data, and also the RCS version of the predecessor. Uponhaving verified all the dependencies, the file may be checked into theRCS 318. Then the FileVersions, TransferConfirm, and RemoteQ tables maybe notified of the successful installation, and the CompleteTime andInstallation Message entries (or columns) may be set on the sourcedatabase, i.e., the database on the site where the file originated. Thisprocess may complete the file transfer procedure in accordance with anembodiment of the present invention.

The above procedure may be applied where the command is either create orsave data. If the command is one of delete data, delete directory, orcopy data, a command sender (such as the command sender 328) may bestarted instead of the file sender 324. The command sender 328 may thenwait for the ACK from the corresponding command executor 330. Havingreceived the ACK/NAK, the acknowledgment may be recorded in the database316, and a panic mail may be sent in case of NAK. In case of delete dataor delete directory, a deletor thread may be spawned, for example, as apart of the command sender 328. This thread may wait for the positiveacknowledgments from all the sites, for example, from its VectorOut.Having received them, the deletor thread can delete the RCS files fromthe local central directory, and then clean the meta-data on its site.This process may replicate to other sites, through meta-datareplication, for example.

FIG. 4 illustrates an exemplary block diagram of a communication system400 in accordance with an embodiment of the present invention. In FIG.4, an arrow 401 illustrates the direction of information flow. Adatabase 402 communicates with a file transfer system (FTS) 404. The FTS404 may be implemented utilizing techniques discussed with respect toFIG. 3, for example. As illustrated, the database 402 may include atrove section 406 and a transfer section 408 which may in an embodimentbe implemented as tables. The trove section 406 may receive commandsfrom a CMD unit 410. It is envisioned that in one embodiment the CMDunit 410 may be a central data management system (CDMS) such as CDMS++.The CMD unit 410 may insert a row into the trove section 406 for eachcommand. The FTS 404 may then determine the current network topology andinsert rows into the transfer section 408, as appropriate. In anembodiment, the trove section 406 can be implemented as a vector.

It is envisioned that in an embodiment the trove section 406 may includeany combination of the following fields: TroveRowId (a unique rowidentity generated by the database); Command (name of the CDMS++command, for example); ObjName (CDMS++ name of the file or directory,for example); ObjId (CDMS++ object identity, for example); Version (RCSversion of the object); Branch (CDMS++ branch of the file object, forexample); OriginSiteId (site identity for the site where the transferrequest originated); Priority (transfer priority of the object);InsertTime (time when the job was inserted into the trove section by theCDMS++ command, for example); PredName (ObjName of the predecessor ofthe current object); PredId (ObjectId of the predecessor of the currentobject); PredType (type of the predecessor object); PredVer (version ofthe predecessor file object); PredBranch (branch/es of the predecessorfile object); FileSize (file size in bytes); ToObjName (destination ofObjName, for example, for a copy data command); ToObjId (destination ofObjId, for example, for a copy data command); ToVersions (list of latestversion of all branches for the file that is being copied); StorageType(type of backend storage); DeltaFile (location of the file where thedelta will be stored); SiteCounter (maximum number of sites to which thecorresponding file has to be transferred); ChkSum (stores the ChkSumfield of the delta file); and/or BBlock (which stands for the Byte Blockfield of the delta file). In an embodiment, the BBlock indicates thenumber of octets a file can be divided into (or in other words the sizeof the file).

Additionally, the FTS 404 may include a trove reader 412 and a transferreader 414. In an embodiment, the transfer reader 414 may be implementedsimilarly to the DBReader module 310 of FIG. 3. In such an embodiment,it is envisioned that the transfer reader 414 reads both the transferand trove sections (408 and 406, respectively). In one embodiment, thetrove reader 412 communicates with the trove section 406, includingreading the contents of the trove section 406, and performs one or moreof the following:

-   -   1. read and mark each row in the trove section 406 as “READ”        once the row is read;    -   2. set a remote site counter (e.g., a SiteCounter entry), for        example, in a column in the trove section 406 to the current        maximum number of spokes to which the local site has to        physically transfer a file;    -   3. calculate the change/delta for a file from its previous        version if the pending command is to save data (which in turn        requires updating the data across all relevant sites);    -   4. create the delta file including delta information, for        example, in a delta directory;    -   5. insert a row in the transfer table for each of the spokes to        which the delta file needs to be transferred (in an embodiment,        the delta file may include the corresponding site id's); and/or    -   6. duplicate the contents of the respective row from the trove        section 406 into the transfer section 408.

Moreover, in embodiments similar to those discussed with respect to FIG.3, in case of a save data command, instead of checking out an RCS file(e.g., the RCS 308) from, for example, a central directory, the filesender (e.g., 324 of FIG. 3) may only send the delta file. The rowobject, which is passed to the file sender may have a record of whereexactly the delta file is stored.

In accordance with an embodiment of the present invention, in case of asave data command, the file installer (e.g., 332 of FIG. 3), instead ofchecking in the received file directly, may check out the predecessorversion from, for example, the central directory, patch it with deltadata, and check the new version into the central directory. The fileinstaller may perform these functions after the dependency checks byverifying the checksum of the buffer file. The file installer mayfurther send appropriate acknowledgments after performing its tasks.Furthermore, in an embodiment, in case of a create data command, thefile installer may verify the checksum of the buffer file (after thedependency checks), install the file into RCS, and send the appropriateacknowledgements.

With respect to re-routing, in an embodiment, FileReceivers (e.g., filereceivers 326 of FIG. 3) may insert one row per transfer job into thetrove section 406 as opposed to inserting multiple rows into thetransfer section 408. Since the routing, in an embodiment, may alreadybe happening with the trove reader 412, it becomes trivial to re-routetransfer requests through the hubs (e.g., hubs of FIG. 2).

In an embodiment, the checksum calculation (discussed with respect toFIG. 3) may no longer be done on the file version identified by the rowobject of, for example, the DBReader module 310. Instead, checksumverification of the delta data may be calculated by the trove reader 412and stored in, for example, the transfer section 408.

In a further embodiment, a message digest 5 (MD5 also known as a one-wayhash function) verification may be done after the file (including thedelta information, for example) has been installed by the fileinstaller. This can be done by checking out the just checked-in versionand calculating its respective MD5 and comparing the result with theprevious MD5 stored in, for example, the database 316 of FIG. 3. Thisconfirms at least one of the following two items: first, that the filehas been installed in RCS; and second, that the file is in factcorrectly installed.

In yet another embodiment, there is a pre-assigned directory on eachspoke where the trove reader(s) 412 store the delta files. These filesneed to exist as long as the send daemons on the local spoke have notreceived positive acknowledgments from their respective remote spokes.After receiving positive acknowledgments, the local delta file can becleaned. This may be accomplished by making use of the Sybase XPtechnology in an embodiment. As discussed above, the trove section 406may have a SiteCounter field which stores the maximum number of sites towhich the corresponding file has to be transferred. The SiteCounter isdecremented each time an ACK (or positive acknowledgment) is received.Once the counter reaches zero, a trigger may be fired to run a storedprocedure, which may in turn make a system call, for example, to performa cleanup of the corresponding delta file(s).

FIG. 5 illustrates an exemplary flow chart of a transfer method 500 inaccordance with an embodiment of the present invention. The transfermethod 500 starts a database transaction by a step 502 in which thetransfer method 500 updates the delta file name in the trove section,e.g., 406 of FIG. 4 (according to a naming convention where applicable).In a step 504, the delta for the file being transferred is calculated.In a step 506, it is determined whether the delta calculation hasfailed. In an embodiment, this can be achieved by utilizing MD5 asdescribed herein. If the delta calculation has failed, a step 508 rollsback the database to ensure that false data is not stored. If the deltacalculation is successful, the method 500 continues with a step 510 inwhich the file delta is stored in a delta directory (DeltaDir), aftercleaning up if required. In a step 512, the checksum and/or bblock ofthe file delta are calculated. A step 514 inserts the required number ofrows into the transfer section (e.g., 408 of FIG. 4). And, in a step516, the transfer method 500 ends the database transaction by settingthe transfer time field in the trove section (e.g., 406 of FIG. 4).

Therefore, in accordance with some embodiments of the present invention,the procedure for receiving a file at a recipient site is independent ofinstalling the file on the recipient site. This bifurcation isenvisioned to yield better performance, be more tunable, provideimproved control, and allow for load balancing (for example, amongdistributed systems). Also, some embodiments of the present inventionaddress the problems associated with keeping live data on a particularsite, spoke, or a domain, in sync with the data on multiple remotespokes in real-time. In a user community distributed across a country oranywhere in the globe, the need arises to have select data be availableon any site at any time. Embodiments of the present invention provideusers access to the latest version of the data as soon as it is releasedinto the system from any site. Therefore, there should not be a need towait for the new data until there is a batch update or a nightlysynchronization, for example.

Additionally, if one of the remote sites is down or cannot acceptexternal data, the systems provided in accordance with some embodimentsof the present invention can temporarily store (e.g., buffer or queue)the new data until the remote spoke is back on-line. Further, the systemcan work with the configuration control mechanisms (CCM) on each siteand can install the new data into the CCM on the remote sites.Additionally, the system can work with meta data (if any) in, forexample, the backend database storage, so that the user commands orinterfaces to the database function accurately during anysynchronization process.

Furthermore, in an embodiment, the present invention works with a FTS toextract the difference (or the delta) from a file and its previousversion. It then calculates the checksum for the delta. The delta andthe checksum are then sent to the appropriate remote sites. This reducesthe network traffic and also speeds up the transfer rates. Thistechnique works very well with an FTS and is very useful in terms ofdoing optimal pre-transfer computations. Also, it is envisioned thatthis technique is especially helpful in situations where relativelylarge files, with relatively small deltas, would have to be synchronizedacross multiple remote sites.

In one embodiment, the present invention takes care of polling thetransfer requests from the database, calculating the delta, calculatingthe checksum, storing them appropriately so that they can be used by allthe send daemons that are functional on the current site. In thisfashion, each send daemon may read the delta and send it, and need notcompute or checkout any file from the respective RCS. As such, thepre-transfer overhead is greatly reduced.

The foregoing description has been directed to specific embodiments. Itwill be apparent to those with ordinary skill in the art thatmodifications may be made to the described embodiments, with theattainment of all or some of the advantages. For example, the schemes,data structures, and methods described herein can also be extended toother applications. More specifically, any type of data may betransferred utilizing embodiments of the present invention. Also, thetransfer systems provisioned in accordance with embodiments of thepresent invention may be configured depending on a specific project,data types, number of users, size of files, location of users, and thelike. Further, the routines described herein may be implementedutilizing Java programming techniques. Therefore, it is the object ofthe appended claims to cover all such variations and modifications ascome within the spirit and scope of the invention.

1-17. (canceled)
 18. A method of transferring a delta of a file, themethod comprising: providing a sender site, the sender site including adatabase, the database having a trove section and a transfer section;providing a file transfer system having a trove reader and a transferreader, the trove reader communicating with the trove and transfersections, the transfer reader having access to the transfer section; andproviding a receiver site having a file installer, the receiver sitereceiving the file delta from the transfer reader, the file installerpatching a previously installed version of the file with the file delta.19. The method of claim 18 wherein the method utilizes an availablebandwidth more efficiently by transferring the file delta between thesender site and the receiver site.
 20. The method of claim 18 whereinthe file transfer system calculates a checksum for the file delta. 21.The method of claim 20 wherein the file transfer system sends both thefile delta and the calculated checksum to appropriate plurality ofremote sites.
 22. The method of claim 20 wherein the checksumcalculation is performed by the trove reader.
 23. The method of claim 20wherein the calculated checksum is stored in the transfer section. 24.The method of claim 18 further including the file installer checking thepatched version of the file into a central directory.
 25. The method ofclaim 18 further including providing an MD5 facility to verify whetherthe file delta has been installed by the file installer.
 26. The methodof claim 18 further including providing an MD5 facility to verifywhether the file delta has been installed correctly by the fileinstaller.
 27. The method of claim 18 wherein the trove section is atable.
 28. The method of claim 18 wherein the transfer section is atable.
 29. The method of claim 18 further including providing an RCS forat least one of the sender site and the receiver site.
 30. The method ofclaim 18 further including configuring the sender site and the receiversite in a hub and spoke network.
 31. The method of claim 18 wherein theact of specifying the next time to install the transferred file on thereceiver site is exponentially backed off for each subsequent try. 32.The method of claim 18 wherein the trove section includes at least onefield selected from a group comprising TroveRowId; Command; ObjName;ObjId; Version; Branch; OriginSiteId; Priority; InsertTime; PredName;PredId; PredType; PredVer; PredBranch; FileSize; ToObjName; ToObjId;ToVersions; StorageType; DeltaFile; SiteCounter; ChkSum; and BBlock. 33.The method of claim 18 wherein the trove reader performs a task selectedfrom a group comprising reading and marking each row in the trovesection as “READ” once that row is read; setting a remote site counterin the trove section to a maximum number of spokes to which the sendersite has to physically transfer the file delta; calculating the filedelta based on a previous version of the file if the pending command isto save data; creating the delta file; insert a row in the transfersection for each spoke to which the delta file needs to be transferred;and duplicating contents of a respective row from the trove section intothe transfer section. 34-36. (canceled)
 37. An article of manufacturecomprising: a machine readable medium that provides instructions that,if executed by a machine, will cause the machine to perform operationsincluding: providing a sender site, the sender site including adatabase, the database having a trove section and a transfer section;providing a file transfer system having a trove reader and a transferreader, the trove reader communicating with the trove and transfersections, the transfer reader having access to the transfer section; andproviding a receiver site having a file installer, the receiver sitereceiving the file delta from the transfer reader, the file installerpatching a previously installed version of the file with the file delta.38. The article of claim 37 wherein the trove reader performs a taskselected from a group comprising reading and marking each row in thetrove section as “READ” once that row is read; setting a remote sitecounter in the trove section to a maximum number of spokes to which thesender site has to physically transfer the file delta; calculating thefile delta based on a previous version of the file if the pendingcommand is to save data; creating the delta file; insert a row in thetransfer section for each spoke to which the delta file needs to betransferred; and duplicating contents of a respective row from the trovesection into the transfer section.
 39. The article of claim 37 whereinthe trove section includes at least one field selected from a groupcomprising TroveRowId; Command; ObjName; ObjId; Version; Branch;OriginSiteId; Priority; InsertTime; PredName; PredId; PredType; PredVer;PredBranch; FileSize; ToObjName; ToObjId; ToVersions; StorageType;DeltaFile; SiteCounter; ChkSum; and BBlock.